Standard permissions model

The Standard Model (Model Application 6.0) introduces a user management model out-of-the-box with a base set of predefined roles and permissions governing access to advanced and administrator functionality, as well as access to fields containing sensitive data and personally identifiable information (PII), such as personal address fields and email fields.

Tip: Details about the Axiell Collections Model Application, including identifying which version is running in your environment, can be found here. Full details about the Standard Model (Model Application 6.0) can be found here.

All new implementations of Axiell Collections now include the standard permissions model with predefined groups such as the Data reader (able to view records in most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. but not edit them), the Data writer (able to view and edit records in most data sources), and Data administrator (with super-user access). Where appropriate, the base set of groups / permissions has already been applied to application objects; for example, the source.email (se) field in acquisition.inf already has read access rights for the PII reader group, write access for the PII writer group, full access for the Data administrator and no access rights for everybody else.

This approach simplifies the permissions model, tightens security by requiring users to be a member of at least one predefined group in order to access Axiell Collections, and eliminates the need to build a permissions model from the ground up as has been the case in the past.

It is anticipated that most groups already defined in systems that upgrade to the Standard Model will map to an equivalent in the standard permissions model. And, if necessary, custom groups can of course be added.

Note: The method for assigning users to groups in Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. is unchanged (and Application Administrators with access to this tool will continue to use it). It is anticipated however that a user access rights management tool will be made available in Axiell Collections itself in a future release, further decreasing reliance on Axiell Designer for user and permissions management.

The groups and permissions defined in the standard permissions model are:

Note: Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.

As the bottom row in the image above makes clear, a user cannot access Axiell Collections unless they are assigned to a group. The following is a summary of permissions assigned to each group:

Active directory group / Collections role	Details
Data reader / `data_reader`	A Data reader: can view but not edit records in most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. ; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.. If a Data reader should have permission to view PII, the user must ALSO be assigned to the PII reader group.
PII reader / `pii_reader`	This group is assigned to users in the Data reader group who should ALSO be able to view PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data writer / `data_writer`	A Data writer: can view records in most data sources and can edit those records; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.; cannot delete records. If a Data writer should have permission to view PII, the user must ALSO be assigned to the PII writer group. Note: A Data writer does not have the import or search and replace permissions.
PII writer / `pii_writer`	This group is assigned to users in the Data writer group who should ALSO be able to view and edit PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data administrator / `data_manager`	A Data administrator has super-user access and: can access all data sources (including Occurrence defaults), but not all administration data sources (such as System lists); can view, edit, and delete records; can view and edit all PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields; can import data and perform search and replace.
App administrator / `$ADMIN`	The `$ADMIN` role is assigned to Application Administrators, providing full access rights and administration control. Application Administrators can access all data sources. Permissions include: view, edit, delete, import, search and replace; unlocking read-only records for editing. Also have access to tools such as Purging saved searches; restoring records using Journal Maintenance, editing record level security on records, etc.
api_svcc_account	This role is intended for the API (not users) and gives view access to relevant data sources (Catalogue, Persons and institutions, etc.), but not to PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields.